Rewrite section on executing Docker tests #2235
Conversation
| You can run `src/ci/docker/run.sh <image-name>` directly. A few important notes regarding the `run.sh` script: | ||
| - There is some configuration used on CI that you may need to recreate. In particular, set `submodules = false` in your `config.toml` so that it doesn't attempt to modify the read-only directory. | ||
| - `<image-name>` corresponds to a single directory located in one of the `src/ci/docker/host-*` directories. Note that image name does not necessarily correspond to a job name, as some jobs execute the same image, but with different environment variables or Docker build arguments (this is a part of the complexity that makes it difficult to run CI jobs locally). | ||
| - If you are executing a "dist" job (job beginning with `dist-`), you should set the `DEPLOY=1` environment variable. |
There was a problem hiding this comment.
If this is mandatory, why aren't we doing it automatically?
There was a problem hiding this comment.
Well, we are doing it automatically, on CI with a bash script executed in GitHub actions, and locally through the ci.py script. run.sh should really be seen as an "implementation detail", and users who want to run a given workflow locally on Linux should use ci.py instead.
src/tests/docker.md
Outdated
| build Rust within the image, and either run tests or prepare a set of archives designed for distribution. The script will mount your local Rust source tree in read-only mode, and an `obj` directory in read-write mode. All the compiler artifacts will be stored in the `obj` directory. The shell will start out in the `obj`directory. From there, it will execute `../src/ci/run.sh` which starts the build as defined by the Docker image. | ||
|
|
||
| You can run `src/ci/docker/run.sh <image-name>` directly. A few important notes regarding the `run.sh` script: | ||
| - There is some configuration used on CI that you may need to recreate. In particular, set `submodules = false` in your `config.toml` so that it doesn't attempt to modify the read-only directory. |
There was a problem hiding this comment.
If I am not mistaken, if we are running a docker image, it already sets submodules = false and our config.toml is not used from the container environment.
We should instead say "make sure submodules are fetched with git ..." I think.
There was a problem hiding this comment.
This always confuses me, I could swear that the Docker build sometimes took data from my root config.toml :) But it seems like it doesn't happen, and yeah, the build expects submodules to be downloaded, because that's what happens on CI.
I reworded the paragraph, let me know what you think.
Suggested in rust-lang/rust#136249 (comment).
CC @jieyouxu